RBIProxy プライベート CA 要件
文書の目的
RBIProxyのHTTPS中継(MITM)署名に使用されるプライベートCAの技術要件を定義します。
この文書は顧客会社 PKI 担当者CAを発行・伝達する際に参照します。
| 項目 | 内容 |
|---|---|
| 適用製品 | RBIProxy (Kubernetes デプロイ) |
| 後続文書 | 02. RBIProxy 사설 CA 적용 엔지니어 가이드 |
📌 要約 — 必ずご確認ください
- キーアルゴリズム: 現在のリリースはRSA 2048ビット以上これは必須です。ECDSAなどの他のアルゴリズムは動作が保証されていないため、RSAを使用してください。
- キー形式: PKCS#8 PEM プレーンテキスト必須 (
-----BEGIN PRIVATE KEY-----).- 推奨方法: 最も単純な**"専用 Self-Signed Root CA 1枚"**方式が推奨されます。Intermediate CA方式も可能ですが、4.5節のチェーン転送制約を必ず確認してください。
- 本CAの用途限定: RBIProxyのHTTPS中継署名専用で発行し、既存のPKI業務用CA（コード署名、メールなど）と分離運用が必要です。
1. 概要
1.1 背景
RBIProxyはユーザーのHTTPSトラフィックを中継(MITM)してRemote Browser Isolation(RBI)サービスに渡します。
このプロセスでRBIProxyは目的のドメイン（例：www.example.comのサーバー証明書を動的に再発行してユーザーブラウザに提供するために、再発行時に署名者(Issuer)として使用するCA 証明書/個人鍵 1組これが必要です。
基本提供CA(製品に含まれる)を使用せずに顧客の自社PKIを活用やろうとする場合、本ドキュメントの要件を満たすCAを準備してください。
1.2 自己CAの適用が検討される場合
次のいずれかに該当する場合は、独自のCAの適用が必要です。
- 基本提供CAの使用に伴うブラウザ警告を削除したい場合
- 顧客別の証明書分離運用が内部セキュリティポリシー上必要な場合
- 既存の社内PKIシステムと統合管理が必要な場合
- 金融業・公共などの監査対応上、固有CAの使用が必要な場合
💡 PoCや単純なテスト段階では、別途作業なしで基本提供CAをそのまま使用できます。
1.3 動作構造 (要約)
- ユーザーPCが外部サイト（例：
https://www.example.com)でHTTPS接続を要求します。 - RBIProxyがリクエストを受け、サーバー証明書を即席で発行するための独自CAによる対象ドメインのしてユーザーブラウザに渡します。
- ユーザーブラウザはプライベートRoot CAを信頼しているため、チェーン検証が通過されて警告なし正常に処理されます。
- RBIProxyは実際の外部サイトにトラフィックを中継します。
※ このフローが動作するためには、ユーザーPCに信頼できるルート認証機関のプライベートルートCAに事前登録されている必要があります（AD GPOなどを通じた配布）。
1.4 全体進行手続き
| 段階 | 主体 |
|---|---|
| 1. 本文書の検討およびCA発行方式の決定 | PKI担当者 |
| 2. CA 証明書/秘密鍵 発行 | PKI担当者 |
| 3. ユーザー PC Root CA 配布 (GPO など) | IT担当者 |
| 4. セキュリティチャネルを通じたファイル転送 | PKI担当者 → 構築担当者 |
| 5. RBIProxyに反映 | 構築担当者 |
| 6. 動作検証 | 両側共同 |
ℹ️ "構築担当者"はRBIProxyを運営中のKubernetes環境に直接作業する担当者を意味します。構築形態に応じて社内ITインフラ担当者、委託SIエンジニア、または製品供給者エンジニアのいずれかになることがあります。本ドキュメント全体で同じ意味で使用されます。"
2. 前提条件
2.1 整備されているべき環境
| 区分 | 要件 |
|---|---|
| プライベート Root CA | 社内独自のRoot CA（または内部PKI）がすでに運用中 |
| ユーザーPC配布体系 | すべての対象PCにプライベートRoot CAが「信頼できるルート認証機関」として配布されています（AD GPOなど） |
| 配布方法 | Windows システム証明書ストレージベース (Edge/Chrome/IE 参照) |
2.2 効果範囲
| ブラウザ/クライアント | サポート | 備考 |
|---|---|---|
| Microsoft Edge | ✅ | Windows システム認証局ストレージの使用 |
| Google Chrome | ✅ | Windows システム証明書ストレージの使用 |
| Internet Explorer | ✅ | Windows システム認証局ストレージの使用 |
| Firefox | ⚠️ 別途設定 | GPOでsecurity.enterprise_roots.enabled = trueまたは独自のTrustStoreに登録 |
| Java/.NET などのアプリケーション | ⚠️ 別途対応 | 各ランタイムのTrustStoreに別途登録が必要です。 |
| macOS / Linux ターミナル | ⚠️ 別途対応 | 各OS認証局ストレージにRoot CA登録が必要 |
3. 伝達すべきファイル (納品物)
次のファイルをセキュアトランスポートチャネルに構築担当者に伝えてください。
| # | ファイル | 必須/選択 | フォーマット | 説明 |
|---|---|---|---|---|
| 1 | CA 証明書(自己署名ルートまたは中間) | 必須 | PEM (.crt / .pem) | RBIProxyが署名用に使用するCA |
| 2 | CA 個人鍵 | 必須 | PKCS#8 PEM プレーンテキスト (.key / .pem) | 対応するプライベートキー |
| 3 | Intermediate チェーン (中間 CAたち) | 条件付き (Intermediate方式) | PEM バンドル | Rootと発行CAの間に他の中間CAがある場合はすべて含む（Rootを除く） |
| 4 | Root CA 公開証明書 | 必須 | PEM | 検証用。Self-Signed Root方式であれば #1と同じファイルも無問題 |
3.1 伝達形式の例
オプション A: 分離ファイル (推奨)
customer-ca.crt ← #1 (単一または #1+#3 チェーンバンドル)
customer-ca.key ← #2 (PKCS#8 プレーン)
customer-root-ca.crt ← #4 (検証用)
オプション B: 統合 PEM
customer-ca-bundle.pem ← #1 + #2 + #3 すべて含む
customer-root-ca.crt ← #4 (検証用)
オプション C: PKCS#12 (.pfx)
customer-ca.pfx ← #1 + #2 + #3 統合 (暗号化されました)
* パスワードは別のチャネルで送信されます
customer-root-ca.crt ← #4 (検証用)
ℹ️ RBIProxy ランタイムはPEMフォーマットを直接ロードします。PKCS#12で受け取った場合、構築担当者がOpenSSLでPEM(cert + key)に変換して反映します。変換過程で秘密鍵を平文状態で一時保管することになるため、セキュリティ上**オプション A(分離ファイル)**が必要です。
3.2 セキュアトランスポートチャネル (推奨)
個人鍵が含まれているファイルは必ず以下の中一つ以上の方法に伝えてください。
| 方法 | 推奨レベル | 備考 |
|---|---|---|
| PKCS#12 + パスワード 別チャンネル 分離 伝達 | ⭐⭐⭐ | ファイルはメール、パスワードは有線/SMS |
| 社内ファイル暗号化ソリューション | ⭐⭐⭐ | 保有している場合 |
| 暗号化USB + 対面伝達 | ⭐⭐ | オフラインでの配信が可能な場合 |
| S/MIME 暗号化メール | ⭐⭐ | 相互認証書の交換が必要です |
| 一般メール添付 (平文) | ❌ | 禁止 |
📌 伝達完了後顧客側で伝達用の平文ファイルを即時破棄してください。
3.3 キー フォーマット 注意事項
Private Keyは次の条件をすべて満たす必要があります。
| 項目 | 必須事項 |
|---|---|
| ラッピングフォーマット | PKCS#8 PEM (-----BEGIN PRIVATE KEY-----) |
| キーアルゴリズム | RSA 2048ビット以上(RSA 3072/4096 可能) |
| 暗号化の有無 | 平文(伝達チャネルで保護) |
PKCS#8 の例 (推奨)
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASC...
-----END PRIVATE KEY-----
PKCS#1 (-----BEGIN RSA PRIVATE KEY-----) を保有している場合 — 変換必須
openssl pkcs8 -topk8 -nocrypt \
-in customer-ca-pkcs1.key \
-out customer-ca-pkcs8.key
暗号化された PEM(-----BEGIN ENCRYPTED PRIVATE KEY-----) を保有している場合 — 復号化必須
openssl pkcs8 -in customer-ca-encrypted.key -out customer-ca-plain.key
# 패스워드 입력 후 평문 PKCS#8로 저장됨
⚠️ 変換/復号化された平文の個人鍵ファイルはセキュアトランスポートチャネル(3.2節参照)でお伝えし、伝達完了後は原本ファイルを即座に廃棄してください。
4. CA 証明書 必須 要件 (X.509 拡張)
CA証明書は次の要件をすべて満たす必要があります。既に他の用途（コード署名、メール保護など）で発行されたCAを再利用することは推奨されません。**"TLSサーバー証明書発行用CA"**ロ新規発行する必要があります。(Self-Signed Root / Intermediate すべて同様の要件)
4.1 X.509 拡張フィールド 必須要件
| 拡張フィールド | 必須値 | 備考 |
|---|---|---|
| Basic Constraints | CA:TRUE | 必須— CA証明書であることを明示 |
| Key Usage | keyCertSign, cRLSign | 必須— 一部のブラウザは未設定時に警告を発生させる |
| Extended Key Usage (EKU) | serverAuth含まれる | 必須— TLSサーバー証明書発行の用途明示 |
| Name Constraints | 未設定が必要 | 設定時に該当ドメインのみ中継可能 |
| Path Length Constraint | pathlen >= 0 | end-entity 発行可能 |
ℹ️ Key Usage / Extended Key Usageは最新のブラウザ（特にChrome系）で徐々に厳格に検証する傾向があります。明示的に設定すれば互換性の観点から安全です。
4.2 キー/アルゴリズム 必須要件
| 項目 | 必須事項 |
|---|---|
| キータイプ | RSA 2048ビット以上(3072 / 4096 可能) |
| 署名アルゴリズム | SHA-256 以上(SHA-1 は使用できません) |
| 有効期限 | 3年以上必要 |
ℹ️ ECDSAなどの他のアルゴリズムは現在のリリースでは動作が保証されていないためRSAの使用が必須です。
4.3 OpenSSL セルフチェック (伝達前)
伝達の前に、以下のコマンドで要件の充足状況を確認できます。
openssl x509 -in customer-ca.crt -noout -text
出力で次の項目を確認:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication
4.4 チェーン検証
openssl verify -CAfile customer-root-ca.crt customer-ca.crt
# 출력: customer-ca.crt: OK
4.5 中間CA運営時のチェーン転送制約
⚠️ このセクションはIntermediate CA方式で運用する際に必ず知っておくべき制約です。Self-Signed Root CA 1章の方式を選択した場合、該当なし。
現象
現在RBIProxyはユーザーブラウザに対して動的に発行されたleaf証明書を送信しますが、その上の段階のIntermediate CAを一緒に送信しないことができます。.
影響
ユーザーPCにRoot CAのみインストールされている場合、ブラウザはleaf → (빠진 Intermediate) → Rootチェーンを完成できないNET::ERR_CERT_AUTHORITY_INVALIDなどの警告を表示できます。
解決方法 — 以下のAまたはBのいずれかを選択してください
A. (推奨) 専用の自己署名ルートCAの使用
- チェーンの長さが1（Root → leaf）なので、中 間段階自体がない → 本制約は該当しません
- 既存のPKIと分離された**"RBIProxy 専用 Root CA 1枚"**を新規発行して伝達
- ユーザーPCには該当するRoot CAのみTrusted Rootに配布
B. Intermediate CA方式を維持する場合
- ユーザーPCにIntermediate CAまで必ず配布
- Windows: "中間認証機関(Intermediate Certification Authorities)" リポジトリに Intermediate CA をデプロイ
- GPO 配布時の Root CA 配布と同じ政策に共に含む必要
- 2段以上の Intermediate チェーンであれば中間段階すべて配布
判定マトリックス
| 受け取ったCAの種類 | ユーザーPCに配布する証明書 | ブラウザの動作 |
|---|---|---|
| 専用自己署名ルートCA | Root CAのみ | ✅ 正常 |
| Intermediate CA (1段) | Root CA + Intermediate CA | ✅ 正常 |
| Intermediate CA (1段) | Root CAのみ | ❌ 警告発生の可能性 |
| Intermediate CA (2段以上) | Root CA + すべての中間CA | ✅ 正常 |
4.6 キー フォーマット 確認
head -1 customer-ca.key
# "-----BEGIN PRIVATE KEY-----" ← PKCS#8 (필수)
# "-----BEGIN RSA PRIVATE KEY-----" ← PKCS#1 (변환 필수)
# "-----BEGIN ENCRYPTED PRIVATE KEY-----" ← 암호화됨 (복호화 필수)
キーアルゴリズムの確認
openssl pkey -in customer-ca.key -noout -text | head -2
# "RSA Private-Key: (2048 bit, 2 primes)" ← 필수
# "ED25519 Private-Key:" 또는 EC 표시 → RSA로 재발급 필요
5. ユーザーPC環境要件
5.1 ルートCAの配布状態確認 (Windows)
# PowerShell (관리자 권한)
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*<사내 CA명>*" }
または GUI:certlm.msc → 信頼できるルート認証機関 > 証明書でのプライベートルートCAの存在確認。
5.2 Firefox を使用する際の追加設定 (オプション)
Firefoxは基本的に独自のTrustStoreを使用します。Windowsシステムストレージを信頼するにはGPOまたはpolicies.json次の設定をデプロイ:
{
"policies": {
"Certificates": {
"ImportEnterpriseRoots": true
}
}
}
またはabout:config → security.enterprise_roots.enabled = true
5.3 macOS / Linux ターミナルサポート
| OS | Root CA 配布方法 |
|---|---|
| macOS | Keychain Access→ システムキーチェーンにRoot CAを追加 → 信頼設定 "常に信頼" |
| Ubuntu/Debian | /usr/local/share/ca-certificates/にコピー後sudo update-ca-certificates |
| RHEL/CentOS | /etc/pki/ca-trust/source/anchors/にコピーした後sudo update-ca-trust |
6. セキュリティ/運用考慮事項
6.1 プライベートキーの保護
- 伝達されたCA秘密鍵はKubernetes Secretに保存され、RBIProxy Podに読み取り専用ボリュームにマウントされます。
- Secret アクセス権限は該当ネームスペースの管理者によって最小化なります。
- 必要に応じて KMS/HSM 連携を別途検討することができます。
6.2 監査ログ
現在の動作
- RBIProxyは動的に発行されたleaf証明書の件別発行履歴を別途ログに残しません(パフォーマンスの考慮)。
- ただし、次のカテゴリのログが記録されます。
- アクセスログ: ユーザーが接続した外部ドメイン (CONNECTログ)
- CA ロードイベント: Pod 起動時 CA 個人鍵 ロード 成功/失敗
- シークレット変更: Kubernetes Audit Log (クラスター レベル)
厳格な監査要件がある場合
発行された leaf 証明書のシリアル番号、発行時刻、対象ドメインなどを全量記録しなければならないなど、別途監査要件がある場合、構築担当者を通じて別途協議リクエストしてください。
6.3 証明書の交換 (ロールオーバー)
- CAの有効期限最小90日前新規発行と伝達が必要です。
- 交換は Kubernetes Secret の再生成 + Pod の再起動のみで反映可能です (短いセッション切断を伴います)。
6.4 廃棄 (Revocation)
- RBIProxyが動的に発行するleaf証明書にはCRL/OCSP URLが含まれていません(一時発行の特性).
- CA自体の廃棄履歴は社内CRL/OCSPシステムに記録されます。
6.5 運用中 CA 変更時
- CA 交換は短いセッションの切断(Pod 再起動、通常1分以内)を伴います。
- 大規模なユーザーへの影響を最小限に抑えるために業務外時間帯変更が必要です。
- 変更前後最低30日以前のCAを廃棄せずに保管してください（ロールバック対策）。
7. チェックリスト (PKI 担当者確認用)
伝達の前に以下の項目を確認してください。
共通 (すべての方式)
-
CA方式の決定: 自己署名ルートCA専用または中間CA
-
"TLSサーバー証明書発行用" CAを新規発行
-
Basic Constraints: CA:TRUE -
Key Usage: keyCertSign, cRLSign(必須) -
Extended Key Usage: serverAuth含まれる（必須） -
Name Constraints 未設定 (または RBI 中継対象ドメインすべてを含む)
-
鍵アルゴリズム = RSA 2048bit以上
-
SHA-256 以上署名
-
有効期限 3年以上
個人鍵フォーマット
-
個人鍵がPKCS#8 PEMフォーマット (
-----BEGIN PRIVATE KEY-----) -
個人キーが平文(暗号化されていません)
ユーザーPCの配布
-
自己署名ルートCA方式: 対象のすべてのユーザーPCのルートCAが**"信頼できるルート認証機関"**にデプロイ完了
-
中間CA方式: ルートCAが**"信頼できるルート認証機関"え、Intermediate CAが"中間認証機関"**と共に配布完了 (4.5節参照)
伝達準備
-
openssl verify -CAfile <Root> <Intermediate>検証 OK (Intermediate方式) -
Root CA公開証明書（検証用）を一緒に送付
-
セキュリティ伝達チャネル(3.2節参照) 準備完了
-
伝達用平文ファイルの廃棄時点事前決定
8. FAQ
Q1. Root CAの秘密鍵を渡す必要がありますか？
A. いいえ。Root CA 個人鍵は社内の最高のセキュリティ資産であるため、渡さないでください。専用Self-Signed Root CAを新規発行するか、既存のRoot CAの下にIntermediate CAを新規発行してお渡しください。
Q2. 既存の内部ウェブサーバー用認証書をそのまま使用できますか？
A. 不可です。一般サーバー証明書(end-entity)はCA:FALSEは発行されて下位証明書署名権限がありません。CA証明書を新規発行する必要があります。
Q3. 自己署名CAと中間CAのどちらを選択すべきですか？
A. 専用 Self-Signed Root CA 1章を推奨します。Intermediate CA方式はユーザーPCにIntermediateまで別途配布する手間があります（4.5節参照）。既存の内部PKI統合監査など特別な要求がない場合はSelf-Signed方式が単純で確実です。
Q4. ECDSAキーで発行してもいいですか？
A. 現在のリリースでは動作が保証されていないためRSA 2048ビット以上に発行してください。
Q5. 有効期限が短いCA（1年など）も可能ですか？
A. 技術的には可能ですが、毎年再伝達/再配布の負担が発生します。3年以上これが必要です。
Q6. Name Constraintsで制限されたCAを与えてもいいですか？
A. 可能ですが、該当の Name Constraint に含まれていないドメインは RBIProxy を通じて接続する際にブラウザ警告が発生します。RBI 中継対象ドメイン範囲を正確に合意した後に設定してください。
Q7. 個人鍵フォーマットが PKCS#1 (-----BEGIN RSA PRIVATE KEY-----)ですが、そのまま送ってもいいですか？
A. 使用できません。openssl pkcs8 -topk8 -nocryptコマンドに変換して伝達する必要があります（3.3節を参照）。
Q8. PKCS#12(.pfx) ファイルだけがあります。このまま送ってもいいですか？
A. 伝達可能です。ただし、RBIProxyランタイムがPEMを使用するため、構築担当者が内部でPEMに変換して反映します。セキュリティの観点から最初から**分離されたPEMファイル（オプションA）**に伝達が必要です。
Q9. 証明書が期限切れになるとサービスはどうなりますか？
A. 有効期限切れのCAをそのままにしておくと、新しいセッションを作成する際にブラウザ警告が発生し、RBIサービスを正常に利用できなくなる可能性があります。満了90日前から更新の準備してください。
Q10. 異なる環境（運用/ステージング）でそれぞれ異なるCAを使用できますか？
A. 可能です。Kubernetes Secretを環境ごとに分離して作成し、各環境のDeploymentに別途マウントすればよいです。運用/ステージングのCAを分離すれば、ステージングのCAが漏洩しても運用に影響がないため、分離が必要です。